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LockBit 2.0 ransomware has been one of the leading ransomware strains over the last six 
months. Recently, the FBI issued a flash alert outlining the technical aspects and tactics, 
techniques, and procedures (TTPs) associated with the LockBit 2.0 affiliate-based 
ransomware-as-a-service. 


Suffice it to say, a plethora of detailed research around this ransomware emerged as a result 


of version "2.0", which surfaced back in the summer of 2021. All these public reports and 
technical undertakings, however, fail to mention a critical aspect of this ransomware strain 
that Microsoft Detection and Response Team (DART) researchers have discovered and is 


something often not discussed when bringing up the topic of ransomware: “buggy code”, and 


the unpredictable consequences that it can induce. 
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This post illustrates a much more direct attempt at ransomware recovery targeting MSSQL 
databases, where we uncovered and further exploited bugs present in the LockBit 2.0 
ransomware code, up to the point where we were able to revert the encryption process for 
these database files and restore them back to a functioning state. This is often an impossible 
task to carry out, given that it implies breaking decades of practical research into 
cryptography-- not simply in theory, but in actual implementation. 


This two-part blog series will outline all the steps taken and challenges overcome, in order to 
restore the damaged database files that served as a critical core of this customer’s 
infrastructure. 


Background 


We uncovered critical inconsistencies with the logic of this ransomware upon our first 
interaction with a LockBit 2.0 afflicted customer, who, incidentally, also purchased the 
software capable of restoring the destruction the ransomware is known to wreak, known as 
"the decryptor" aspect of ransomware. 


The unfortunate customer was soon to find out that the claims the affiliate-based 
ransomware distributor made, about paying the ransom resolves to obtaining the decryptor 
capable of restoring the effects of the encryption, were very dubious in their assertions. Upon 
attempting to use this purchased decryptor to restore critical database files, the customer 
was met with very disappointing results and was perplexed as to why the restoration of these 
database files was not going as expected, and what steps to take next. 


At some point, DART became engaged with this customer, obtained access to both the 
encryptor and decryptor aspects of the ransomware, and with suspicions that "faulty crypto” 
was at play, analysis commenced. 


Our observations on the encryptor and identifying its anomalies 


One of the first things we can do to make our lives easier when suspecting faulty 
encryption/decryption is to first avoid the urge of digging into any literature regarding the 
densely obtuse aspects of cryptography, or even more menacingly, modern cryptography. 
Instead, use the power that Sysinternals handy-dandy Procmon provides in monitoring file 
I/O with the hopes of spotting any kind of anomalies or inconsistencies when either the 
encryptor or decryptor is running. 


Through this monitoring we should get a quick (correct) picture of how the 
encryption/decryption algorithm is implemented, assuming that it is not doing all of this in 
memory and indeed going through the I/O manager as is generally the case. 


For instance, Figure 1 shows the encryptor in action on a test dummy file we created. It’s 
worth noting, when assuming faulty crypto algorithms are at play, to test on a variety of file 
sizes to see how/if they pan out differently. We often see a common mistake on larger sized 
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files (at least 4GB or greater), especially in 32-bit encryptors, not understanding that the 
larger the file size gets, the closer we get, and eventually cross, into signed territory. These 
mistakes can lead to incorrect checks on file sizes, how the internal file pointer is set, and so 
on, that can introduce unintended corruption by the encryptor. Something to always keep an 
eye out for. 

Proces... Operation Path Result Detail 

"v2c.exe &CreateFile C:\Users\pro\Desktop\1GBTEST txt SUCCESS Desired Access: Read Data/List Duelo Write Data/Add File, Delete, Disp 


"v2c.exe &QueryStandardinformati...C:\Users\pro\Desktop\1GBTEST txt SUCCESS ft bd Ue! 405,120, End 15/120, |NumberOfLinks: 1 
Wv2c.exe Scanorama Aaa ek aS SUCCESS End 5i 


th: 4,096, I/O Flags: Non-cached, Priority: Normal 
4,096, I/O Flags: Non-cached, Priority: Normal 


"v2c.exe HAWriteFile I/O Flags: Non-cached, Priority: Normal 


™v2c.exe Eae. C: \Users\pro\Desktop\1GBTEST. txt SUCCESS CreationTime: 4: 54:38 AM, LastAccessTime: 56: 36 AM, 
"v2c.exe &SetRenamelnformation... C:\Users\pro\Desktop\1GBTEST txt 1 xt.lockbit 
™v2c.exe &CloseFile C:\Users\pro\Desktop\1 gbtest.txt.lockbit SUCCESS 


Figure 1. Test #1 of the encryptor in action 
Test #1: high-level observations 


e It increases the file size 

It only encrypts the first 0x1000 bytes from the start of the header (in theory, enough to 
kill off any header metadata) 

e Appends some data at the end of the original file size (0x200 bytes) 

e Appends a ./ockbit extension to the original filename 


Spoiler: The data that it appends to the end of the encrypted file is the required decryption 
information that the decryptor utilizes as part of its restoration process. Each file is encrypted 
with a unique 16-byte initialization vector (IV) and AES256 key. Both are stored, encrypted 
with a modified cha-cha dance, at the end of each individual encrypted file. The decryptor in 
turn knows how to find this “decryption blob”, extract the unique IV and AES256 key, and 
then leverage them for the decryption. Other data is stored as well in these blobs, such as 
the original file size and the AES block size. 


Our test #1 from the Procmon output in Figure 1 shows that the encryptor alters the original 
size of the file it is about to corrupt, so it is only appropriate that it retains this original 
information somewhere when the decryptor begins to attempt its restoration process. At least 
this is the theory. In practice, as we’re soon to find out, something quite different has the 
potential of happening. 


Testing the 1GB file was a good start, but let’s try a much larger file and again, observe the 
behavior of the encryptor through Procmon. 
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Process Name Operation Path Result Detail 


i v2c.exe C.\iDefenseitest txt SUCCESS Desired Access: Read Data/List Directory, Write Data/Add File, Delete, Disposition: Open, Op’ 
W v2c.exe QueryStandardinformationFile C:\iDefenseltest txt SUCCESS AllocationSize: 68,719,476,736, EndOfFile: 68,719,476,736, NumberOfLinks: 1, DeletePendin: 
fl v2c.exe SetEndOfFileinformationFile C:\iDefenseltest.txt SUCCESS EndOfFile: 68,719,477,248 

W v2c.exe C.\iDefenseitest txt SUCCESS Offset: 0, Length: 4,096, I/O Flags: Non-cached, Priority: Normal 

fll v2c.exe C:\iDefense\test txt SUCCESS E : 4,096, Normal 

W v2c.exe 

i v2c.exe C.iDefenseltest txt SUCCESS /O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, F 
fl v2c.exe C:\iDefense\test txt SUCCESS /O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, F 
fl v2c.exe C.\iDefenseltest.txt SUCCESS 1/0 Flags: Non-cached, Paging I/O, Synchronous Paging I/O, 
iW v2c.exe C:\iDefenseltest txt SUCCESS 1/0 Flags: Non-cached, Paging I/O, Synchronous Paging I/O, 
il v2c.exe C.\iDefenseitest txt SUCCESS 1/0 Flags: Non-cached, Paging I/O, Synchronous Paging I/O, 
fi v2c.exe C.\iDefense\test txt SUCCESS 1/0 Flags: Non-cached, Paging I/O, Synchronous Paging I/O, 


Figure 2. Test #2 for encryptor in action 
Test #2: high-level observations: 


e Starts off like our first test but ends drastically different 

e Procmon curiously does not generate a Result for the WriteFile operation when 
appending the decryption blob 

e It seems to further encrypt, at 65,536-byte intervals, more data 


Having some clear differences from our first test run, the second one intrigues us enough to 
continue digging deeper with the suspicion that something is seriously not right here. It gets 
even more intriguing when we try to view the call stack for the WriteFile operations that 
follow the instance where Procmon was unable to tell us the Result of appending the 
decryption blob. 


BABE FASE MS REA TM 


Time of Day Process Name Operation Path Result Detail 


10.18:39.9767356 AM IE v2c. exe CreateFile CWDelonseitest bt SUCCESS Desired Access. Read Data/List Directory, Wate Data/Add File, Delete, Disposition: Open, Opbons. No Buffenng, Non-Directory 
10 18:39.9849909 AM IE v2c.ex0 QuoryStandardinformatonFée C WDetenseltest txt SUCCESS AlocationSize. 68,719,476,736, EndOfFile: 68,719,476,736, NumberOfLinks. 1, DeletePending Falso, Directory. False 

10. 18:39.9850934 AM [iiv2c. exe SetEndOfFileintormatonFile CDetonseitest txt SUCCESS EndOfFée 68,719,477 248 

10.18:39.9858342 AM IE v2c exe ReadFie CNDetensellest it SUCCESS Offset: 0, Lengt 4,096, 1/0 Flags: Non-cached, Priority: Noemai 

10.18:40.0078791 AM ME v2c.ex0 CNDetensellest bt g 


10:18:40.0428773 AM [Ei v2c. ex0 
10-18:40.0429287 AM fillv2c exe 
10:18:40.0478491 AM [le vac 
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Event Process Stack 


Frame Module Locabon Ack#ess Path Frame Module Location Address Path 
Ko FLTMGRSYS FLTMGR SYS + Ox4aSd Oetfte0SOacc4aSd C\Windows\System32idriversF LTMGR SYS 

Ki FLTMGR SYS FLTMGR SYS + Ox4500 Oettfff8050acc45a0 C\Windows!System32idrvorsF LTMGR SYS 

K2  FLIMGRSYS FLTMGRSYS + 0x4112 Qxftfff80S0ace4 112 C:\Windows!System32idrversFLTMGR SYS i i 

K3 FLTMGRSYS FLIMGRSYS+OxSefe Odtfte0S0acctefe C.\Windows)System32driversF LTMGR SYS 222222? Is this real 222 

Ka nioskniexe ntosieniexe + Ox10a829 Oxiffff80506702929 C\Windows'system32intoskrni exe 

K5 Mlosiniexe mosimiexo + Ox802c45 MAB0506 d2045 CMWindowsisystem3IZntoskmi exe 

K6 ntoskmiexe ntoskmiexe + 0x636706 Oxttfff80506C36706 C\Windowsisystem32\ntoskmi exe 

K7 miosimiexe nlosimlexe + Oxld3cl5 OxfffffB05067d3c15 CWindowsisystem3Zintoskmi axe 


Us  wowôicpudi wowôtcpudi»OxIcbc 07704 Icbe C Windows) System32iwow64cpu dit 
U9 wowSicpudi wow6tcpudi + 0x199a 0x7704199a C\Windows!System32iwow64cpu dil 
U10 wow6tcpudl wowGtcpudi»0x1199 0x77041199 C\Windows!Systom32\wow64cpu dli 


Ui wosia wow64 di + Oxc77a Ox71tf90ade77a C\Windows)\System32wow64 dil 
Un wwa wow64 cil + Oxc637 Ox71190adc637 C:\Windows) System32wow64 di 


U13 moia tdi dll + Ox? 186b Ox711926118eb C\Windowes'System 32intdil dit 
Um ndia nidiLdi + 0x7 1743 Ox71t1926117d3 C\Windows'System32intdil dil 

U15 maa Mall dl + 0x71770 0x7119261177e C\Windows\System 32d dil 

U16 ntdidi tdi dil + Ox7 1e7c¢ Ox770cte7¢ C.\Windows\Sys WOW 64intdll dit 
U17 v2cexe v2c. exe + Oxa0842 0x430842 C\Users\Adman'Desklopiv2c exe 
U18 keme32di kemel32di+0x16359 075086359 C\Windows!SysWOW64\kemel32 dt 
U19 maa midi dll + Ox67c14 0x770b7c14 C\Windows!Sys WOW 64intdll dit 
U20 ntaa Mdidi + Ox6 7be4 0x770b7be4 C\Windows Sys WOW64intdll dil 


Figure 3. Viewing the call stack for the WriteFile operations 


Every WriteFile operation following the empty Result in the yellow highlighted row looks like 
the Event Properties box on the right: empty. This is very strange indeed and requires a 
deeper introspection than Procmon can give us. Before departing from the almighty 
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Procmon, it continues to show its worth by providing us with a valuable vantage point of 
where to begin looking at: the call stack. We can see that at offset +OxA0842 is where we 
presumably never return from. 


Now feels like the right time to introduce our favorite toolset for any deep troubleshooting into 
the picture: Time Travel Debugging (TTD) 


What exactly is the issue? 


Prior to introducing the TTD framework into the picture, we will first load the encryptor into 
IDA Pro and go to that offset identified by Procmon to observe the code at that location. 
Doing so, we can see that we are at the return address of what is a call to ntdll!NtWriteFile. 
Depending on what we can further spot in the disassembly or decompilation, the following 
plan is to re-run the encryptor again, but this time under the control of 77 Tracer to generate 
some runtime data that we can work against. 


.text:004A0825 lea eax, [ecx+Lb_crypt_t.byte_offset] 

. text : 004A0828 push eax 

. text : 004A0829 push [ecx+Lb_crypt_t.encrypted_size] 

.text:QO4A082C lea eax, [ecx+Lb_crypt_t.io_status] 

.text:QO4A082F push [ecx+Lb_crypt_t. buffer] 

.text:004UA0832 push eax 

. text : 004A0833 push ecx 

. text : OOUA0834 push 0 

. text : OOUA0836 push 0 

.text:Q04A0838 push [esit+lb_encrypt_file_t.file_handle] 

.text:004UA083B call lb: :resolve_ntwritefile ; append tail 
.text:O004UA084UO0 call eax 

. text : O04UA08U2 test eax, eax 

.text:004A0844 jns resolve_nt_remove_io imptable OQUAO71F 
. text : OOUAD8UA or eax, OFFFFFFFF 


Figure 4. Code responsible for writing the encrypted contents back to disk 


Let’s also show the cleanup decompilation of this piece of code as well, to observe ata 
higher level. 


t=& Letior 1e->byte_offset; 
z= et \e->encrypted_size; 
f= let Jalue->buffer; 
t is = & tion e->io_status; 
fi = tior /->file_handle; 
WriteFil lb: :resolve_ntwritefile(); 
if ( WriteFile(hfile, 0, 0, tionVaLue ToStatu fi d 
&& !_InterlockedExchangeAdd(& etionkey->field_48, OxFFFFFFFF 
Figure 5. Decompilation of Figure 4 


l = 


As shown in both Figure 4 and 5, we can spot that something is off here; the NTSTATUS 
return value for the write file is not handled correctly. In fact, it’s flat-out wrong. One way that 
we can demonstrate the consequence of this improper handling of the write file operation is 
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to ask whether the encryptor operates asynchronously. The reasons for introducing this in 
our inquiry will be explained shortly. 


But if we do dig a bit into the binary inside IDA, we can confirm the asynchrony of the 
encryptor, implemented through I/O completion ports. The actual file encryption is done via a 


callback routine executed as a thread, and very interestingly for the debugging enthusiasts, 
hidden threads. 


! e f = NtCurrentPeb()->NumberOfProcessors; 
g_CPU_COUNT_O = N f z 
t = lb:: 


dword_4FB9EC = lb::mem_alloc((4 * g_CPU_COUNT_0)); 
if ( dword_UFB9EC ) 
{ 
for ( i = 0; i < g_CPU_COUNT_0; ++i ) 
*(dword_UFB9EC + 4 * i) = lb: :api::create_hidden_thread(1b::crypt::init cleanup, g IOCP_HANDLE_0O); 
goto LABEL_5; 
} 


= CreateThread(0, 0, lpStartAddres 


threa S, LpParameter, 0, LpThreadId); 
if ( hthread != INVALID_HANDLE_VALUE 
{ 
] j = lb::resolve_NtSetInformationThread(); 
NtSetInformationThread(hthread, ThreadHideFromDebugger, 0, 0); 
} 
return ht 1d; 


Figure 6. Encryptor multi-threading initialization and using hidden threads that carry out the 
encryption 


What this call to NtSetInformationThread does is set the HideFromDebugger flag inside the 
internal, executive thread structure, which guarantees that the debugger will never receive 
any debug events for this thread, effectively missing the controllable execution of these 
threads. Something to be aware of when attempting to debug this encryptor in the traditional 
manner. Since we plan to use TTTracer, these anti-debug shenanigans are moot, and we 
can ignore them completely. 


This is great and all, but what exactly is the issue here with the NTSTATUS value? First, 
LockBit 2.0 devs mistakenly assume all unsuccessful NISTATUS values are signed. For 
instance, the following ones are very relevant to the encryptor given its asynchronous 
behavior and are clearly not negative numbers. 
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0x000000C0 A user-mode APC was delivered before the given Interval expired. 
STATUS_USER_APC 

0x00000101 The delay completed because the thread was alerted. 
STATUS_ALERTED 


0x00000102 The given Timeout interval expired. 

STATUS_TIMEOUT 

0x00000103 The operation that was requested is pending completion. 
STATUS_PENDING 


Figure 7. NTSTATUS values 


Second, and more importantly, they entirely neglect the handling of pending I/O operations: 
STATUS_PENDING. And given the asynchronous nature of I/O on Windows, this in theory 
could be every file I/O operation. Further, given that the encryption is carried out 
asynchronously as well through I/O completion ports, ntd/l!NtWriteFile can and will return 
STATUS_PENDING, which the caller must properly account for. How does one account for 
it? Patience. (See WaitForSingleObject and ZwWaitForSingleObject) 


Not doing so will lead to unpredictable and potentially destructive behavior as LockBit 2.0 is 
mistakenly assuming success after each write operation when the return value is not signed. 
When multiple threads are at play, which they will be, you now create a situation that can 
result in all these worker threads writing at unpredictable intervals. Seems like a minor 
ordeal, but because of this mishandling, the entire stability of the encryptor is now in 
question. These effects naturally spill over to the decryptor as well. 


lIO_STATUS_ BLOCK 


NtwriteFile( 
IN HANDLE FileHandle, 
IN HANDLE Event OPTIONAL, 


IN PIO_APC_ROUTINE ApcRoutine OPTIONAL, 
IN PVOID ApcContext OPTIONAL, 
OUTPIO_STATUS_BLOCK IoStatusBlock, 


IN PVOID Buffer, 

IN ULONG Length, 

IN PLARGE_INTEGER ByteOffset OPTIONAL, 
IN PULONG Key OPTIONAL); 


); 


The operating system implements support routines that write |O_STATUS_BLOCK values to 
caller-supplied output buffers. For example, see ZwOpenFile or NtOpenFile. These routines 
return status codes that might not match the status codes in the |O_STATUS_ BLOCK 
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structures. If one of these routines returns STATUS_PENDING, the caller should wait 
for the I/O operation to complete, and then check the status code in the 
10_STATUS_BLOCK structure to determine the final status of the operation. 


If the routine returns a status code other than STATUS PENDING, the caller should rely on 
this status code instead of the status code in the |O_STATUS_ BLOCK structure. 


About the broken decryptor (and decrypting files that it couldn’t) 


Having now identified at least one critical flaw that can result in faulty crypto, let’s shift our 
attention to the decryption process itself, because our primary goal is to confirm, and then 
hopefully implement, a capacity to do what the purchased decryptor was supposed to do. 


From the customer, we were given several MSSQL encrypted database files which had the 
potential of being correctly decrypted. The reason that we can make such a claim is that the 
required decryption information (recall our earlier Procmon adventures) was still intact 
somewhere in the file. Not where it’s supposed to be, but it’s there, nonetheless. This 
misplacement, a direct result of the improper handling of the write file operation outlined 
above, is what causes the decryptor to miss retrieving this blob of data. This mishandling can 
even unwittingly truncate or expand the original file size. Simply having the decryption blob 
information present in the encrypted binary does not really mean anything at this stage of 
what we're trying to accomplish. 


One of the first things that we tried to get the decryptor up and running accurately, was to 
remove all the data that follows the decryption blob in the encrypted database file, giving it 
the appearance of being “correctly” appended, as it was originally intended to be. We then 
ran the decryptor against it (under TT Tracer) to see what would happen. We failed to decrypt 
the file with this approach but with the resulting TTD trace, we have a window to peek into 
and identify the flaws in our wishful approach. 
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but it’s not at the end/tail of the file as its supposed to be 


Going through the generated trace file, we were able to identify that the decryptor does 
indeed find the decryption blob correctly now and furthermore, is able to successfully decrypt 
it to acquire the necessary IV and AES key for decryption. However, the file still does not get 
decrypted. Digging deeper, we identified the issue being in how it tries to compare two 
LARGE_INTEGERs, that of the incoming, encrypted file size and the AES block size stored 
in the decryption blob data that it assumed it appended correctly. 


General Details Previous Versions 


| | encrypted_database_file.lockbit 


Type of file: | LOCKBIT File (.lockbit) 


Opens with: 4) Pick an app Change... _ Figure 9. File size and the encrypted 
Location: D: 
Size: 79.9 GB (85,899,268,096 bytes) 


Size on disk: 80.0 GB (85,899,345,920 bytes) 


database file we’re working against 
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// disassembly responsible for initiating this sequence, by storing the incoming file 
size 

.text:00428721 mov esi, dword ptr [eaxtlb_encrypt_file_t.og_filesz] ; fetch the 
LowerPart of the file size 

.text:00428724 mov eax, [eaxt+lb_encrypt_file_t.og_filesz.anonymous_0.HighPart] ; 
fetch the HighPart of the file size 

.text:00428727 mov [espt+iCh], eax ; store the HighPart of the file size 
.text:0042872B lea eax, [esp+3E8h+var_268] 

.text:00428732 push eax 

.text:00428733 mov [esp+18h], esi ; save the LowerPart of the file size 


// in the TTD trace, looking at the incoming file size being stored as a 
LARGE_INTEGER 

00428724 8b4024 mov eax,dword ptr [eaxt+24h] 

ds:002b:1c9e0024=00000013 

0:014> dd @eax 

1c9e0000 00000000 00000000 00000000 00000000 

1c9e0010 00000000 00000000 00000000 00000000 

1c9e0020 fffec200 00000013 00000000 00000001 


// size of the incoming file 

0:014> dt ntd1l1!_LARGE_INTEGER 1c9e0020 QuadPart 
0x00000013`fffec200 

+0x000 QuadPart : 0n85899264512 


// code that does the check after the offset has been calculated from the decryption 
blob 

.text:004288E6 mov eax, [esitlb_encrypt_file_t.byte_offset.anonymous_0.HighPart ] 
.text:004288E9 add edx, ecx 

.text:004288EB adc edi, eax 

.text:004288ED cmp [esp+iCh], edx ; now check the LowerPart 

.text:004288F1 jnz size_check_fail_cleanup 

.text:004288F7 cmp [espt+i8h], edi ; now check the HigherPart 

.text:004288FB jnz size_check_fail_cleanup 
__success_go_for_decryption_of_encrypted_content 


// go to the location where the check and “bug” is at 

0:014> dx @$calls(0x4288ED).First().TimeStart.SeekTo() 

Time Travel Position: 1CC3E8:F20 [Unindexed] Index 

0:014> u . 14 

decryptor+0x288ed: 

004288ed cmpdword ptr [esp+ich],edx ; compare against LowerPart 

004288f1 jne size_check_fail_cleanup ; they have to match, otherwise decryption is 
skipped 

004288f7 cmp dword ptr [esp+18h],edi ; compare against the HighPart 

004288fb jne size_check_fail_cleanup ; they have to match, otherwise decryption is 
skipped 

0:014> r edx 

edx=00000200 ; AES block size calculated out of the data inside the decryption blob 
0:014> dd @esp+ic 11 

1a73fb9c fffec200 ; LowPart of incoming file size, failing when being compared to the 
size of the decryption blob 


0:014> r edi 
edi=00000014 ; very revealing, this tells us where the decryption blob should 
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actually be (what the HighPart should be) 

0:014> dd @esp+18 11 

1a73fba4 00000013 ; HighPart, we see our cutting off all the data after the 
decryption blob breaks the logic here 


Based on the TTD trace, simply cutting off all the data that follows the decryption blob won’t 
work either, but we can spot what the issue is and even where the decryption blob is 
originally supposed to be: minimum at offset 0x1400000000 in the file. The high part of the 
large integer for the incoming file is at offset 0x1300000000, but it fails when compared to 
the original size that was calculated out of the decryption blob: 0x1400000000. But even 
before that, the comparison of Oxfffec200 and 0x200 also fails, since it’s expecting to have 
correctly calculated the AES block size, which it did not. 


Realizing this, we decided to “push” the decryption blob up to its proper offset, and then 
again cut off all the data that followed it, to recreate the encrypted file once more into what 
should be its originally intended structure. Once done, we re-run it through the decryptor and 
excitedly await the results. 
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blob before we re-run the decryptor against it 


Upon running the decryptor this time around, we successfully decrypted the file! 
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decryptor_pp+0x288ed: 

004288ed cmp dword ptr [esp+0Ch],edx ss:002b:0271fb9c=00000200 
0:007> r edx 

edx=00000200// edx, as expected is 0x200 

0:007> dd @Qesp+c 11 


0271fb9c 00000200 // aes block size has correctly been calculated this time 
0:007> t // step into, to validate the jne 

decryptor_pp+0x288f1: 

004288f1 jne decryptor_pp+0x28c0a (00428c0a) [br=0] 

0:007> r zf 

zf=1 

0:007> t // step into to compare the next check for the HighPart 
decryptor_pp+0x288f7: 

004288f7 397c2414 cmp dword ptr [esp+14h],edi ss:002b:0271fba4=00000014 
0:007> dd @esp+14 11 

0271fba4 00000014 // we see that they're the same, and the decryptor works as 
expected 


0:007> r edi 
edi=00000014 


0:007> t 
0:007> r zf 
zf=1 
8888h: 85 86 DD 93 45 4E C9 BA 73 7E BE AS 31 1C A4 35 _tY“ENEes~.¥1.05 Gh: 01 OF 0A 66 08 02 GA BG GB GA GA GG GA BA BA BO .............. re 
9918h: CB 54 E3 Fé 2B AC 2B 17 88 2B 1D AF BB C9 AC 3E ETAd+-+.*+. ~»f-> : 00 00 0G 8B 0G BB 01 0G 63 68 BB 8A 63 1B Dé 88 ........ RRA 
1F DB F1 EE 27 F7 5B AB AG 21 BA 2B FO B8 14 D4 .Oñt'+[« !o+3 .6 : 80 00 0G 0G 04 0G BB BB AG 8B 07 GB BA 96 87 BB ........ C 
86 12 8B 26 Bb 27 C4 A4 9B GA BC 36 6B DD BA 6E t.<84'Ä=>.6kÝ.n |0038h: 02 00 00 6B GB BA 0G BG B BA BB OB 7E DS ƏB C4 ............ ~Õ.À 
C4 60 50 4D C6 BA 07 A9 13 88 39 02 23 32 34 SF Ä`PME2.0..9.#24_  |80048h: 68 68 68 0G BB GO BB GO BB GO BG GG BA BA BA OB ................ 
B5 62 FF D4 67 B4 BA B4 8C D4 BC DF OC 89 4A 91 pbyOg’. €0.8.%)° : 00 68 66 GG 6B BB 0G 0G GG GB BG GA GA GA 68 BO ................ 
5D CE 26 92 84 E3 5D 56 FC 54 8A 88 Ab 1E DC Be Ji&’.alvaTS*!.U° : 30 00 68 GB 01 BB 0O BB 31 0G 8G 0G 0G OB GB 8G B....... ETOS 
87 28 1F AF 55 88 29 5D AE 12 BD BC E8 48 07 8F ¢(.-U*)]*.33eH.. : 00 2E 00 7F 00 7F 0G 81 68 83 0G 87 OO 8B GO BF ......... AAA 
@5 38 38 64 AB JE 22 1A SC BF CB 3E 58 GF 26 73 .8@d«~".\;E>Po&s | : 00 93 08 9D 0A A7 00 B1 68 B1 68 BS 0A BI GG BD .“...§.+.ż.p.1.} 
D7 C7 9F FS 48 45 28 76 AS E4 C3 4A DS EA 00 C2 xÇÜöHE(vyäãjðe.A | : 00 C1 00 CB 08 E7 8 F1 80 FB OG 05 61 15 01 1F .Á.Ë.ç.ñ.0...... 
BD 3D 6F 33 A9 9D AE 42 05 11 92 E5 A9 2E 28 27 .=030.°B..’A0.(' : 61 2F 61 33 61 3D 61 3D 61 55 61 65 01 65 61 65 ./.3.=.=.U.e.e.e 
3C 8D 22 CO E9 67 E9 5B Dé A7 7A 4 CB 63 AB 23 <."Aégé[OSz.Ec # @1 65 81 65 01 65 81 65 81 75 81 75 01 75 G1 7F .e.e.e.e.u.u.u.. 
85 22 58 BC 89 86 62 26 A3 01 ED C4 32 EC 6E B6 .."Xihtb&f. iA2ind 01 89 01 AS 61 AF 01 BF 81 DB 81 E3 01 3B 04 05 .&.¥.-.7.0..;. 
1: 98 E8 9C BE 1F 95 DB 48 98 3E 97 BC 3F DB 89 1C .ée3.eDH™>-.70.. 80 22 6D AB 54 D5 40 8A Dé 48 F1 3D 76 9E 75 84 e"neTO@SOHK=veu, 
: 1D B@ EA F3 28 3D A2 17 FE BA 8E FC 18 B4 3E E5 .*86(=¢.poZii. “>a 0a 62 68 6B 0G AG GG FF FF FF FF 0G 0A BA 60 68 ..... WWW... 
1: 20 18 CO 2E EF BO C8 2E 23 B7 44 5C 7A 90 EE 86 .A.i°E.#-D\z.it : 68 66 0G 6B 0A GB BA GA GA GA GA GA BG BA 8G BO ................ 
»: 1B 96 68 9A 42 Fé 87 40 37 A8 5F A4 32 86 53 B7 .-hSBO¢@7™_=2}S- (9198h: 00 68 6B 6B BB BB GA BG BG GB BB GA GA GA BA BO ................ 


Figure 11. (L) Encrypted file; (R) Successfully decrypted file 


While this has the deceptive appearance of some kind of success, we must remain ever 
cognizant of the fatal bug that’s inside the encryptor. The critical flaw by these ransomware 
developers in misunderstanding how NTSTATUS values work, and the consequences they 
can have for naive thread synchronization. Given that we don’t want to be unwitting victims 
of naivety ourselves, we quickly realized that the immensity of the problem was just now 
slowly starting to reveal itself. 


Coming up in Part 2 


In the second part of this series, we will shift our focus to outlining the issues that the 
decryptor poses, uncover the file structure of the database files that we’re dealing with, throw 
in a little bit of crypto magic into play, and take the necessary steps to achieve our ultimate 
goal: the successful restoration of all encrypted database files. 
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